A Fully Automated GUI-based ASIC Verification Platform
A more efficient verification process is explained
By Di-Ping Chou
The verification process, whether ASIC implementation verification, software module function verification, or system
integration, is a time consuming but essential part of the product development process. Compared with a costly bug fix at the final product delivery stage, thorough verifications at the early stage are a worthwhile investment of time.
Here is a suggested verification platform that offers a user-friendly, automated environment for regression testing. This approach transforms a time consuming and labor intensive regression test into a simple point-and-click process with very little human-labor required.
Philips Semiconductor's mixed-signal CDMA baseband mobile processor IC created a GUI-based and automated verification platform to help with the verification efforts.
For the chip vendor, the typical wireless handset solution includes RF (transmit/receive) front end, IF unit, standard specific baseband processor, programmable DSP, and a microcontroller. The level of integration depends on the individual semiconductor vendor. For this project, the concentration was on the CDMA baseband handset
processor IC and the IS-95 compliant firmware modules. Hence we involved only the following two devices: CDMA baseband processor (CDMA processor for short)-in both an FPGA emulation and real IC-and the single-chip DSP/microcontroller combo, in this stage of verification process.
We used a fast prototyping board, Aptix's (San Jose) System Explore MP3, as the main testing vehicle of the CDMA baseband processor. The CDMA processor communicates with the DSP chip via two serial interfaces; one for
control/communications, the other is dedicated for I/Q data transceiving. The DSP/microcontroller is programmed through the DSP emulator via a JPEG port. To simplify the task, no microcontroller levels of operations were used during the baseband IC and handset verification process.
For the majority of the verification process, the main focus was on verifying the operation of the CDMA processor. We checked its functionalities against the IC specifications, using both an FPGA emulation version and the actual IC.
Certain build-in features in the CDMA processor eased debugging via external debug pins, which helped o facilitate the IC verifications.
Verification Setup
To realize the desire of process automation and ease the load of test vector development, we adopted the following steps in creating the verification process. First, we developed a multilevel Matlab GUI program suite, from register level to regression suite level. Second, we enabled programming over LAN for controlling/configuring the
test equipment and triggering the spread spectrum I/Q input data.
Programming the Matlab GUI
The fact that the CDMA processor is fully controlled by the DSP processor creates a hurdle for the IC designer during the verification and debugging process. Controlling and configuring the CDMA processor requires DSP assembly level programming experience. We developed a GUI to help those IC verification team members with little assembly level programming experience. This shell, in Matlab, also
offers real time visualization of the despreaded data. Whenever the pilot acquisition/searching module is activated we can plot the strengths and phases of the acquired pilot data on a 'real time' basis. Also, several levels of GUI interfaces were created to meet the different requirements of different stages of verification.
The CDMA processor supports a total of more than 60 control/configuration registers. Depending on their functions, these registers can be grouped (not exclusively) into several
different subsets. Some of the subsets are:
- PN generator subset
- Finger subset
- Searcher subset
- Transmit subset
Figure 1 shows the searcher subset GUI interface, which replaces the user programming the DSP registers through assembly level instructions with a simple "fill in the blanks" form.
The
compile
button takes care of scanning all programmed registers and properly converts the corresponding order and register contents into the
required serial control interface format. The
go
button calls the associated DSP emulator batch file, which does the following steps in sequence: downloads the properly formulated data file to the data memory space, takes an executable generic program file suitable for outputting blocks of data to the control/configuration interface, resets the DSP chip, and executes the program.
Similarly, the
Decompile
button uses a previous saved and formatted file and reformats and displays the
corresponding register location and order. The
Decompile
button is very useful for fine tuning the test vectors.
The second and higher levels of a GUI program can easily be constructed from the test vector files created in the 1st level. All the GUI buttons correspond to each of the specific functions verified in the register level testing. The
show
button displays all of the important information for each test vector.
We created application-dependent Matlab buttons to speed up the verification. We found that writing some DOS batch files eases the effort of creating the Matlab GUI buttons, further reducing our interface and development chores.
Programming over LAN
Another building block used in creating the verification platform was the interconnection of all our equipment and the target devices. By internetworking the PC and logic analyzer, we have a bridge for controlling
and configuring the logic analyzer via the PC. We use an HP16500C logic analyzer and pattern generator that supports the LAN-based TCP/IP protocol. This LAN compatibility fits our needs very well.
The setup and configuration functions are included as a part of the automation process, but some manual steps are still necessary. First of all, the configuration settings for the analyzer and/or pattern generator for each test should be set up, saved, and stored in the logic analyzer (LA). By using the FTP
(File Transfer Protocol) command
get
, it is possible to retrieve the files and save them in a PC directory. We can then use the FTP command
put
to upload the proper configuration files onto the LA system directory and set up the instrument via the LAN whenever we need a new setup. The push button
SetUp LA
, as shown in figure 1, does just this in a corresponding DOS batch file.
The pattern generator requires similar steps for setup. Since the I/Q test inputs are in ASCII
format, one extra step is needed to convert these files into the required HP pattern generator format. We generate the I/Q test data inputs from Cadence Alta Group's SPW simulation tools. We use the SRI (Stimulus Response Interface) software from Aptix to take the SPW simulation vectors as inputs, convert them into the proper HP pattern generator format, and download the vectors to the pattern generator. The FPGA version of the CDMA processor was also synthesized and compiled by the Aptix MP3 software.
After the system finished converting and reformatting the inputs, we set up the prototype module via the Matlab GUI interface, ran the pattern generator, and reviewed the captured timing waveforms on the logic analyzer with a simple click of a GUI push button. The results and responses (for example, the captured waveform patterns from the logic analyzer) of the various test vectors are plotted (if applicable), stored, and saved in PC for later verification.
Building the Regression Suite
We save the following files for every successfully tested test vector in our regression suite:
- 1) CDMA processor register configuration file
- 2) Logic analyzer control/configuration file
- 3) Properly formatted pattern generator test input file
- 4) Corresponding timing waveform files generated by the logic analyzer
We load the first three files for each test vector. At the end of the test, we compare the
captured waveforms (or data files) with the prestored reference data from file 4 to check for any discrepancies.
In our case, we built one regression suite for each function offered by the CDMA processor. All the regression suites can be linked together by simply creating a top level Matlab GUI program.
We have presented our approach for setting up an IC verification platform for a CDMA baseband processor. With some limited overhead in terms of creating the Matlab GUI files, it transforms time
consuming and labor-intensive IC verifications into a simple point-and-click operation.
Di-Ping Chou is a system engineer at Innovation Center, Telecom Terminal Group, Philips Semiconductor, where he is responsible for the system aspects of the next generation mobile phone ASIC.
